1. Field of the Invention
This invention relates generally to the testing of digital signal processing units and, more particularly, to the interruption of code execution to determine the status of various portions of the target processor implementing the code or initiate a new procedure. A processor can have a protected pipeline or a non-protected pipeline. When the target processor has a non-protected pipeline, the code executing on the processor can have interruptible portions and can have non-interruptible portions.
2. Description of the Related Art
As microprocessors and digital signal processors have become increasingly complex, advanced techniques have been developed to test these devices. Dedicated apparatus is available to implement the advanced techniques. Referring to FIG. 1A, a general configuration for the test and debug of a target processor 12 is shown. The test and debug procedures operate under control of a host processing unit 10. The host processing unit 10 applies control signals to the emulation unit 11 and receives (test) data signals from the emulation unit 11 by cable connector 14. The emulation unit 11 applies control signals to and receives (test) signals from the target processor 12 by connector cable 15. The emulation unit 11 can be thought of as an interface unit between the host processing unit 10 and the target processor 12. The emulation unit 11 must process the control signals from the host processor unit 10 and apply these signals to the target processor 12 in such a manner that the target processor will respond with the appropriate test signals. The test signals from the target processor 12 can be a variety types. Two of the most popular test signal types are the JTAG (Joint Test Action Group) signals and trace signals. The JTAG signal provides a standardized test procedure in wide use. Trace signals are series of signals from a multiplicity of junctions in the target processor 12. While the width of the bus interfacing to the host processing unit 10 generally have a standardized width, the bus between the emulation unit 11 and the target processor 12 can be increased to accommodate the increasing complexity of the target processing unit 12. Thus, part of the interface function between the host processing unit 10 and the target processor 12 is to store the test signals until the signals can be transmitted to the host processing unit 10.
In the test and debug of the target processor, specified internal events result in a halt of the target processor (i.e., for analysis of the configuration of the processor) or in a change of processor program execution. These specified events are monitored by dedicated apparatus. Upon detection of the occurrence of the event, the monitoring apparatus generates an event signal. The events signal or signals are applied to a trigger device. The trigger device issues a trigger signal that results in the change of operation of the target processor. Referring to FIG. 1B, the operation of the trigger generation unit 19 is shown. Monitoring apparatus 18, including event signal generation units 181 through 18N, is typically included in the target processor 12. The event generation units 181–18N each monitors some portion of the target processor to determine when a specified condition (or conditions) or event is present. When the specified condition is detected by the event signal generation unit monitoring the condition, an event signal is generated. The event signals are applied to the trigger generation unit 19. Based on the event signals applied to the trigger generation unit 19, a trigger signal is selected. Certain events and combination of events, referred to as an event front, generate a selected trigger signal that results in certain activity in the target processor, e.g. a debug halt. Combinations of different events generating trigger signals are referred to as jobs. Multiple jobs can result in the same trigger signal or combination of trigger signals. In the test and debug of the target processor, the trigger signals can provide impetus for changing state in the target processor or for performing a specified activity. The event front defines the reason for the generation of trigger signal. This information is important in understanding the operation of the target processor because, as pointed out above, several combinations of events can result in the generation of a trigger signal. In order to analyze the operation of the target processing unit, the portion of the event front resulting in the trigger signal must be identified in order to determine the reason for the generation of the trigger signal.
A development system can create a number of test and debug events. These test and debug events halt the code execution so that analysis can be made of the state of the processor. In a real-time test and debug environment, it is desirable to allow the service of interrupt signals designated as real time interrupts to continue after a debug event generates an execution halt. Because the test and debug events are generally accepted at the next instruction boundary, a test and debug event can halt the code execution at a non-interruptible point in the code execution.
In a protected pipeline, real-time interrupt procedures can occur at any instruction boundary, so it is not a problem that code execution halts in a non-interruptible point. Once the code execution is halted, real-time interrupt procedures continue even though the code was not interruptible at the point at which the code execution was halted. In other words, in a non-interruptible code portion, real time interrupt procedures can continue in a protected pipeline independent of whether code execution is halted at a non-interruptible point.
In an unprotected pipeline, the situation is much different than for a protected pipeline. In the unprotected pipeline, real time interrupts cannot occur at any arbitrary instruction boundary because of architectural problems (e.g., delayed branches in flight) or instruction-to-instruction relationships that can be disturbed (the global enable bit is disabled to indicate these code areas). Because the pipeline sequence must be preserved in an unprotected pipeline, this rule is obeyed when code execution is halted by a test and debug event.
When a test and debug event is allowed to halt code execution in an unprotected pipeline at a non-interruptible point in the code execution, real time interrupt services must be blocked because these activities would corrupt the code so that the code execution could not be resumed after the interrupt return. To preserve the ability to service real-time interrupts after code execution halts, test and debug events must be blocked until code execution reaches an interruptible point.
However, an application developer may find it desirable to halt the code execution at a non-interruptible point in the code to observe the machine state even though real-time interrupt are blocked, and other times, may find it desirable to delay code execution halts to points where the code is interruptible (i.e., allowing service of real time interrupts after execution halts). Having once determined that the halt is desirable even if non-interruptible code is being executed, the user/host processor unit must be alerted to the corruption of the procedure executing at the time of the code halt.
A need has therefore been felt for apparatus and an associated method having the feature that a program execution halt taken in a non-protected pipeline during a non-interruptible portion of the code identified. It would be another feature of the apparatus and associated method to permit the user/host processing unit to determine whether a program execution halt is implemented during a non-interruptible portion of program executing on a non-protected pipeline. It would be further feature of the apparatus and associated method to permit the implementation of a code halt during a non-interruptible code portion to be communicated to user/host processing unit.